Mobile device credit account

ABSTRACT

Providing for a mobile communication device (MCD) credit account and credit transactions by way of such an MCD is described herein. As an example, a credit account sponsored by a financial or commercial entity can be associated with a unique ID of an MCD. The MCD can interface with another electronic device and initiate credit transactions, such as commercial purchases, credit transfers, currency conversions, and the like, via the interface. Further, rules provided by the sponsoring entity can guide such transactions, enforcing credit limits, for instance. A management component can then synchronize transactions conducted by the device with a server of a financial institution over a remote communication interface, such as the Internet or a cellular/mobile communication network. Accordingly, a mobile device can replace a traditional credit card in transacting credit business.

CROSS REFERENCE TO RELATED APPLICATIONS

The subject application for patent is a Continuation claiming priorityto co-pending U.S. Non-Provisional patent application Ser. No.13/851,639 entitled MOBILE DEVICE CREDIT ACCOUNT, filed on Mar. 27,2013, which is a continuation of U.S. Non-Provisional patent applicationSer. No. 12/705,709 entitled MOBILE DEVICE CREDIT ACCOUNT, filed on Feb.15, 2010, now issued as U.S. Pat. No. 8,429,071, which is a continuationof U.S. Non-Provisional patent application Ser. No. 11/943,362 entitledMOBILE DEVICE CREDIT ACCOUNT, filed on Nov. 20, 2007, now issued as U.S.Pat. No. 7,689,508, the entireties of which are incorporated herein byreference.

BACKGROUND

Recent advancements in mobile communication technology have enabled notonly real-time, remote communication, but also an ability to accomplishsuch communication without utilizing a stationary telephonic device.Specifically, cellular technology, Bluetooth technology, and the like,have enabled individuals to travel and conduct remote, real-timecommunicate simultaneously. In addition to voice communication, remotedigital information exchange in general has also been accomplished byway of such devices. As a result, the recent generation has aptly beencharacterized as an age of “information on the move”.

As mobile communication devices, e.g., cell phones, smartphones,multi-mode phones, personal digital assistants (PDAs), etc., become moreportable and more personal, such devices have become central to the newmobile communication age. For instance, mobile devices can be utilizedto browse the Internet, shop online, and download songs, video, and thelike. In addition, consumers can access electronic mail, instantmessaging (IM), personal planning applications, such as calendars andtask lists, entertainment applications, and so on; essentially, themobile communication device has come to replace stationary personalcomputers in many aspects. As mobile device popularity increases,service providers also adapt to make their products and servicesaccessible by way of such devices. However, the rate at which mobilecomputing and communication technology progresses is typically fasterthan the rate at which service providers can incorporate newapplications for mobile technology; consequently, data services may notbe fully leveraged at a given point in time for such devices.

In recent years, the world has also begun to transition to a cashlesssociety. For instance, payroll checks no longer need to be physicallyprinted, cut, and distributed to employees. Rather, electronic transferto a bank account provides a more convenient mechanism to distribute,receive and deposit payroll funds. Similarly, other trends have greatlyaffected traditional banking in other respects. For example, in the notso recent past customers would personally visit a bank branch to receivepersonal service from a teller; today, such visits happen lessfrequently. Automated teller machines (ATMs) were responsible for thefirst transition away from personal teller service. Today, as theInternet continues to grow in popularity, online banking has become anadditional mechanism to accomplish financial transactions withoutvisiting a bank branch. Accordingly, ‘personal banking’ has become anadditional aspect of modern society greatly impacted by the new digitalinformation age.

SUMMARY

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview of the claimed subject matter. It is intended toneither identify key or critical elements of the claimed subject matternor delineate the scope thereof. Its sole purpose is to present someconcepts in a simplified form as a prelude to the more detaileddescription that is presented later.

Providing for a mobile communication device (MCD) credit account andfinancial credit transactions by way of such an MCD is described herein.As an example, a credit account sponsored by a financial or commercialentity can be associated with a unique ID of an MCD (e.g., mobile phone,smart-phone, personal digital assistant (PDA) or the like). The MCD cancouple with another electronic device over a remote communicationinterface and initiate credit transactions, such as commercialpurchases, credit transfers, currency conversions, and the like.Further, rules provided by the sponsoring entity can guide suchtransactions, enforcing credit limits, for instance. A managementcomponent can then synchronize transactions conducted by the device witha server of a financial institution over the remote communicationinterface. As a result, an MCD can be utilized instead of a traditionalcredit card in transacting credit business.

According to further aspects, peer to peer credit transfer by way of anMCD is provided. A first MCD, having an associated credit account, canutilize a remote communication interface to couple with an electronicdevice also affiliated with a financial account. The electronic devicecan be an electronic server of a financial institution, an automatedteller machine (ATM), an electronic cash register, a second MCD, and soon. A credit execution component can facilitate transfer of funds fromthe credit account to the financial account via the remote communicationinterface, and can update each account with the results of the transfer.The transfer can also incorporate encryption technology and security inorder to mitigate a likelihood of fraudulent activity involved in thetransfer. Accordingly, the subject innovation provides for a mobile,electronic credit mechanism suitable for modern electronic commerce.

In addition to the foregoing, one or more aspects of the subjectdisclosure provide for mobile credit convenience features incorporatedinto an MCD. Such a device can convert funds from one currency toanother based on a location of the MCD, for instance. In addition, acredit account can be sub-divided into multiple accounts sponsored bydifferent commercial or financial entities. The sub-divided accounts canbe utilized to accrue benefits provided by such entities (e.g.,discounts in transacting with a sponsoring entity, money-back benefits,frequent usage points, frequent traveler benefits, and so forth). Anaggregation component can compile and manage accrued benefits andprovide a review of such benefits to a user of an MCD. As a result, theuser can be informed of the availability of such benefits on the MCD andoptimize their use in MCD credit transactions.

To the accomplishment of the foregoing and related ends, the one or moreembodiments comprise the features hereinafter fully described andparticularly pointed out in the claims. The following description andthe annexed drawings set forth in detail certain illustrative aspects ofthe one or more embodiments. These aspects are indicative, however, ofbut a few of the various ways in which the principles of variousembodiments may be employed and the described embodiments are intendedto include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of an example system that associatesa credit account with a mobile communication device (MCD) andfacilitates credit transaction via the MCD.

FIG. 2 depicts a block diagram of a sample system that provides a remoteinterface between electronic devices to facilitate credit transactionsfor an MCD credit account.

FIG. 3 illustrates a block diagram of a sample system that providesautomated currency conversion based on data determined about an MCD.

FIG. 4 depicts a block diagram of an example system that facilitatesautomated payroll deposit to an MCD credit account in accordance withvarious aspects.

FIG. 5 illustrates a block diagram of a sample system that cansub-divide a credit account into sub-accounts sponsored by one or moreentities, accumulate and manage benefits related thereto, and apportioncredit amongst such accounts.

FIG. 6 depicts a block diagram of a sample system that provides secureinteractions for remote credit transfer in accordance with one or moreaspects.

FIG. 7 illustrates a flowchart of a sample methodology for facilitatingcredit transactions for an MCD credit account in accordance with one ormore aspects.

FIG. 8 depicts a flowchart of an example methodology for providingmanagement of MCD credit and credit sub-accounts according to additionalaspects.

FIG. 9 illustrates a flowchart of an example methodology for providingautomated currency conversion for an MCD credit account.

FIG. 10 depicts a sample operating system for implementing variousaspects of the subject disclosure.

FIG. 11 depicts a sample remote communication environment to facilitateremote data exchange in accordance with one or more embodimentsdisclosed herein.

DETAILED DESCRIPTION

Various aspects are now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of one or more aspects. It may be evident, however, thatsuch aspect(s) may be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to facilitate describing one or more aspects.

In addition, it should be apparent that the teaching herein may beembodied in a wide variety of forms and that any specific structureand/or function disclosed herein is merely representative. Based on theteachings herein one skilled in the art should appreciate that an aspectdisclosed herein may be implemented independently of any other aspectsand that two or more of these aspects may be combined in various ways.For example, an apparatus may be implemented and/or a method practicedusing any number of the aspects set forth herein. In addition, anapparatus may be implemented and/or a method practiced using otherstructure and/or functionality in addition to or other than one or moreof the aspects set forth herein. As an example, many of the methods,devices, systems and apparatuses described herein are descried in thecontext of an ad-hoc or unplanned/semi-planned deployed wirelesscommunication environment that provides synchronized transmission andretransmission of SFN data. One skilled in the art should appreciatethat similar techniques could apply to other communication environments.

Referring now to FIG. 1, a block diagram of a sample system 100 isdepicted that associates a credit account 102 with a mobilecommunication device (MCD) 104. The credit account 102 can be affiliatedwith an authorized service account (e.g., a mobile service agreementprovided by a mobile communication service provider) of the MCD 104, forinstance, or affiliated with a unique ID 106 of the MCD 104 that iscorrelated to a device user. In addition, the credit account 102 can besponsored by a financial institution, commercial entity that providescredit services, or the like. Furthermore, system 100 can facilitatesynchronization of account activity initiated at the MCD 104 with aserver (108) of the financial and/or commercial entity sponsoring thecredit account. Accordingly, system 100 can effect substitution of theMCD for a traditional credit card, facilitating remote and/or personalcredit transactions and synchronization with a sponsoring server (108).

According to particular embodiments, system 100 can include a mobileidentification component 110 that receives a unique ID 106 of an MCD104. The unique ID 106 can be affiliated with a user of the MCD (notdepicted), and identify both the MCD 104 as well as the user. Inaddition, the mobile identification component 110 can provide the uniqueID 106 to a mobile-credit interface component 112 that associates acredit account 102 with the unique ID 106 of the MCD 104. The creditaccount can be any suitable mechanism, such as a personal credit limit,for extending financial credit to a consumer (including, e.g., anindividual person, a business, a corporation, a non-profit organization,and so on). Furthermore, the consumer can be uniquely associated withthe unique ID 106 of the MCD 104. For example, a service account of amobile service provider (not depicted) can associate billing informationfor the consumer with the unique ID 106. Alternatively, or in addition,consumer credit information (e.g., social security number, personalidentification number [PIN], etc.) can be associated with the unique ID106. Accordingly, information related to credit history (e.g., loanhistory, payment schedules, delinquent or missed payments, and so on)can be accessed and reviewed by way of the unique ID 106. In such amanner, a financial institution or commercial lending agency can accesspersonal and/or business information (e.g., credit history) involved inestablishing the credit account 102.

In addition to the foregoing, system 100 can include a managementcomponent 114 that synchronizes a contemporaneous state of the creditaccount 102 at the MCD 104 and a state of the credit account 102 at afinancial account server 108. Such contemporaneous state can include aconcurrent credit limit, a credit balance, a recent credit transactionhistory including expenditures and payments to the credit account, orthe like. More specifically, a time, amount, date, location (e.g.,global positioning system [GPS] location) of a transaction,product(s)/service(s) involved, name of transacting entities (e.g.,including the unique ID 106 and/or user PIN number, discussed above)including a merchant or vendor, or names or identification informationassociated with a private peer to peer transfer, or like information,can be determined for each credit transaction and can be recorded at theMCD 104. Such information can constitute the contemporaneous state ofthe credit account 102. Any of such information, or like transactionrelated information, can be synchronized at the financial account server108 by management component 114.

Management component 114 can utilize any suitable remote communicationarchitecture (e.g., as depicted and discussed in more detail withrespect to FIG. 2, infra) to accomplish synchronization of the creditaccount 102. For instance, a mobile communication network (e.g., acellular network), a data network (e.g., the Internet), a radiofrequency (RF) transmitter/receiver pair (e.g., RF identification-likedevice), or an optical transmitter/receiver pair (e.g., optical scanneror transceiver), or the like, or a combination thereof, can be utilizedby management component 114 to interface the MCD 102 and the financialaccount server 108. Therefore, updates or requests at the financialaccount server 108 can be accomplished in order to synchronizetransaction information at the MCD 104 and the financial account server108 (e.g., to supervise the credit account 102, approve a transaction,provide billing statements, acknowledge and record payment information,provide credit benefits, facilitate account integrity and security, andso forth). As a result, where a conventional credit transaction couldrequire a contemporaneous interface to an electronic server of afinancial institution (e.g., to verify the credit account and/or receivetransaction approval—often provided by a merchant over a telephoneline), the MCD 102 and management component 114 can provide such accessinstead (or in addition). Accordingly, not only transactions with acommercial merchant can be accomplished, but peer to peer transactionsas well.

By associating the credit account 102 with a unique ID 106 of an MCD 104(and, e.g., with a social security number, PIN number, or the like, of auser of the MCD 104), credit transactions can be facilitated withoutproviding a credit card, or reciting/entering account and/or expirationnumbers, or other identifying information. The MCD 104 can store andprovide such information to a transacting party (e.g., a merchant), andprovide an interface to a financial account server 108 forsynchronization (e.g., including transaction approval). Therefore, forinstance, system 100 can conduct a purchase or payment between remotedevices (e.g., see FIG. 2, infra), where funds are drawn from the creditaccount 102, via an MCD 104. As another example, a credit voucher (e.g.,a pre-paid gift card, gift certificate, or the like) can be purchasedvia funds from an MCD account (102, 104) and transferred directly orindirectly to another account. Alternatively, the credit voucher can besent to a physical address in the form of a physical gift card voucheror sent to an e-mail address as an e-gift card, and can be ‘redeemed’ bydrawing on funds from the credit account 102. Purchase and/or transferof the credit voucher can be initiated and conducted at the MCD 104.

In addition to the foregoing, security mechanisms can be incorporated inconjunction with an MCD credit account (102, 104). Security can beimplemented so that only an authorized user can access credittransactions, and to reduce a likelihood that unauthorized access and/oruse of the credit account (102) occurs (e.g., see FIG. 6). Thus, system100 can provide for personal credit transactions by way of an MCD 104instead of a credit card or credit card identification information(account number, expiration date, card ID number, etc.).

As used in this application, the terms “component”, “system”,“interface” “mechanism”, and the like, are intended to refer to acomputer and/or electronic-related entity, either hardware, software,software in execution, firmware, middle ware, microcode, and/or anysuitable combination thereof. For example, a component may be, but isnot limited to being, a process running on a processor, a processor, anobject, an executable, a thread of execution, a program, and/or acomputer. One or more components may reside within a process and/orthread of execution and a component may be localized on one computerand/or distributed between two or more computers. Moreover, thesecomponents can execute from various computer readable media havingvarious data structures stored thereon. The components may communicateby way of local and/or remote processes such as in accordance with asignal having one or more data packets (e.g., data from one componentinteracting with another component in a local system, distributedsystem, and/or across a network such as the Internet with other systemsby way of the signal). Additionally, components of systems describedherein may be rearranged and/or complemented by additional components inorder to facilitate achieving the various aspects, goals, advantages,etc., described with regard thereto, and are not limited to the preciseconfigurations set forth in a given figure, as will be appreciated byone skilled in the art.

Furthermore, various aspects are described herein in connection with amobile communication device (MCD). An MCD can also be called asubscriber unit, mobile station, mobile, remote communication device, orpersonal electronic device. A subscriber station can be a cellulartelephone, a cordless telephone, a Session Initiation Protocol (SIP)phone, a multi-mode phone, a smart-phone, a personal digital assistant(PDA), a handheld device having remote connection capability (e.g.,wired or wireless such as licensed cellular radio frequency [RF],unlicensed wireless, general RF transmission, optical transmission, andso on). In addition, the MCD can include any suitable processing deviceconnected to a wireless modem, RF transceiver, optical transmitter ortransceiver, or similar mechanism facilitating wireless communicationwith another processing device.

In addition to the foregoing, various aspects or features describedherein can be implemented as a method, apparatus, or article ofmanufacture using standard programming and/or engineering techniques.The term “article of manufacture” as used herein is intended toencompass a computer program accessible from any computer-readabledevice, carrier, or media. For example, computer-readable media caninclude but are not limited to magnetic storage devices (e.g., harddisk, floppy disk, magnetic strips . . . ), optical disks (e.g., compactdisk (CD), digital versatile disk (DVD) . . . ), smart cards, and flashmemory devices (e.g., card, stick, key drive . . . ). Additionally,various storage media described herein can represent one or more devicesand/or other machine-readable media for storing information. The term“machine-readable medium” can include, without being limited to,wireless channels and various other media capable of storing,containing, and/or carrying instruction(s) and/or data.

As used in this application, the term “or” is intended to mean aninclusive “or” rather than an exclusive “or”. That is, unless specifiedotherwise, or clear from context, “X employs A or B” is intended to meanany of the natural inclusive permutations. That is, if X employs A; Xemploys B; or X employs both A and B, then “X employs A or B” issatisfied under any of the foregoing instances. In addition, thearticles “a” and “an” as used in this application and the appendedclaims should generally be construed to mean “one or more” unlessspecified otherwise or clear from context to be directed to a singularform.

Referring now to FIG. 2, a system 200 is depicted that facilitatescommercial and/or peer to peer credit transactions by way of an MCD 202and an electronic processing device 204 in accordance with additionalaspects of the claimed subject matter. System 200 enables the MCD 202 toact as a credit card, both by associating the MCD 202 with a creditaccount 206 (e.g., as described supra at FIG. 1) and by interfacing theMCD 202 with an electronic processing device 204, located remote fromthe MCD 202, that is associated with another account (208). As a result,funds within the credit account 206 can be transferred to the otheraccount (208) to affect a purchase, payment, or the like.

According to particular embodiments, system 200 can include a remotecommunication interface 210 that enables remote communication betweenthe MCD 202 and a second communication device (204). The remotecommunication interface 210 can include a wired connection, such as anEthernet cable, or the like, or various suitable wireless connections.For example, the remote communication interface 210 can utilize a mobilecommunication network (e.g., a cellular network) where suitable (e.g.,if the MCD 202 and the electronic device 204 are both cellularcommunication devices or can access a suitable mobile communicationnetwork). Further, the remote communication interface 210 can be a datanetwork such as the Internet, an intranet, and so on, an RFcommunication interface (e.g., including Bluetooth and like RFtechnologies), an optical frequency communication interface (e.g., anoptical scanner and/or transmitter/receiver pair), or combinations ofthese or of like interfaces (210). In general, the remote communicationinterface 210 enables the MCD 202 and electronic processing device 204to exchange information, including information related to a credittransaction.

According to further embodiments, system 200 can include a creditexecution component 212 that transfers funds between the credit account206 and the account 208 associated with the electronic device 204. Thecredit execution component can perform the transfer to facilitate acredit payment between such accounts (206, 208), or facilitate a creditpurchase, or the like. The credit execution component 212 can include anelectronic processor, for instance, that can facilitate the transactionbetween accounts (206, 208). Such a processor can execute an applicationthat adds/debits funds for each account (206, 208), calculates acontemporaneous balance for each account (206, 208) (e.g., based oninformation regarding prior balance stored at each account [206, 208] ifavailable), and/or records time, date, location, party identity, orproduct/service information (e.g., name, price, discounts or sales,coupons, gift certificates, etc.), or a combination thereof or of thelike, associated with the transaction.

As a particular example of the foregoing, intended to illustrate but notto limit the disclosed subject matter, credit execution component 212can reside at the MCD 202, as part of the remote communication interface210, at the electronic device 204, or a combination of these or of othersuitable locations. The credit execution component 212 can receive aname/identity of a product/service from one of the devices (202, 204),and obtain a price for the service/product from the electronic device204. Once the price is determined, credit account 206 can be accessed byway of the MCD 202 to determine whether an available credit exceeds theprice. If so, credit execution component 212 can debit the creditaccount 206 an amount equal to the price, and add to the account 208 acommensurate amount (equal to the price). Further, credit executioncomponent 212 can calculate local taxes (e.g., stored in memory at theMDC 202, electronic device 204, or by the Internet access through theremote communication interface 210), fees, surcharges, or the like, andinclude such into the price and debit/credit the accounts (202, 204)accordingly.

As another, non-limiting example, a user can desire to transfer funds toanother entity by way of a credit voucher (e.g., gift card, giftcertificate, and so on, purchases from a bank, financial institution,commercial credit sponsor, etc.). For instance, user ‘A’ can purchase agift card for $1000 to send to entity ‘B’ (e.g., a person, merchant,business, credit lender, financial institution, or the like). Entity ‘B’can receive the gift card at a second device (204) and deposit the $1000into any suitable account (208) associated with the second device (204).The account (208) need not be affiliated with a lender sponsoring thecredit account (206) (e.g., the receiving account [208], associated withentity ‘B’, need not be affiliated with a bank that sponsors the creditaccount [206] from where the credit voucher funds originate.)Additionally, a credit voucher as described can be forwarded directly toan ATM machine, or like machine, to dispense a sum of cash for entity‘B’, up to the voucher funds. Alternatively, or in addition, a portionof the $1000 credit voucher funds can be deposited into entity ‘B’saccount (208) and another portion dispensed as cash at an ATM.

According to additional examples, a physical representation of thecredit voucher (e.g., a plastic ‘gift’ card) can be purchased from thecredit account 202 at the MCD 204 and mailed to a physical address toaccomplish a transfer. The physical representation (or gift card) canenable an individual named on and/or possessing the gift card to redeemfunds from the credit account 202. As a further example embodiment, thecredit voucher could be sent as an electronic gift card (e.g., e-giftcard) to an e-mail address, instant message address, and so on. A codecontained within the e-gift card could then be utilized to redeem funds(e.g., $1000 in the above example) from the credit account 202. Likevariations of the foregoing, although not specifically articulatedherein, are also incorporated into the subject disclosure.

According to particular embodiments, credit execution component 212 canaccess one or more financial servers sponsoring the accounts (206, 208)to obtain transaction approval prior to facilitating a transaction.Alternatively, or in addition, transaction rules (established by asponsoring entity) for the accounts (206, 208) can be obtained fromrespective devices (202, 204) and credit execution component 212 canallow or deny the transaction based on the transaction rules, withoutprior approval from a sponsoring entity itself. For instance,transaction rules could specify that transfer of funds from creditaccount 206 can occur without contemporaneous approval only if anavailable balance on the credit account 206 exceeds the amount of fundsby 20% (e.g., for a $500 purchase/funds transfer, the available balanceexceeds $600). If the transaction rule is satisfied, the transaction canbe affected, if not, prior approval from a financial server (e.g., seeFIG. 1 at 108) must be obtained before credit execution component 212executes the transaction. As a result, a transaction can be facilitatedaccording to predetermined rules established by a sponsoring creditentity, even if a contemporaneous link to the credit entity cannot beestablished at the time of the transaction (e.g., insufficient cellularcoverage). Once a link to the credit agency can subsequently beestablished, the details of the transaction can be synchronized at aserver associated with the credit entity (e.g., as described withrespect to management component 114 at FIG. 1).

In accordance with one or more additional aspects, peer to peertransactions can also be facilitated by remote communication interface210 and credit execution component 212. For example, if a user of MCD202 desires to transfer funds to a friend, MCD 202 can be connected tothe friend's MCD (204) (e.g., by way of a cellular network) in order toaccomplish such a transfer. If the friend's MCD (204) has an account(208) associated with it, credit execution component 212 can facilitatea transfer of funds from the credit account 206 to the friend's account(208) (e.g., checking account, savings account, credit account, or thelike) in a manner substantially similar to that described above.Specifically, a server of a financial entity sponsoring the creditaccount 206 can be consulted for transaction approval or the transactioncan be facilitated in accordance with predetermined rules stored at theMCD 202 (and, e.g., synchronization with the server to update results ofthe transaction).

It should be appreciated that the electronic device 204 can be anysuitable device that can be correlated to a financial account (e.g.,checking, savings, credit, money market, certificate of deposit, etc.),or an electronic sum of funds. For instance, the electronic device 204can be an ATM, an electronic cash register, a credit card reader (e.g.,equipped with Bluetooth communication capabilities, optical transmissioncapabilities, a landline, wired, or wireless interface to acommunication network [210], and so on), a second MCD as describedherein, or any combination of these or like devices. System 200therefore, can provide a mechanism for purchasing goods or services,transferring funds from person to person and/or entity to entity,commercial investment, and so on, via a mobile credit account (202,206).

Referring to FIG. 3, a block diagram of a sample system is depicted thatcan provide location and conversion features for an MCD (304) creditaccount 302 as described herein. Specifically, system 300 can determinea location of a device and perform suitable currency conversionsappropriate for such location. If an MCD 304 travels from the UnitedStates to China, for instance, currencies associated with the creditaccount 302 can be displayed in Yen as opposed to Dollars. In addition,actual funds exchanged or disbursed (e.g., at an ATM) can be in Yeninstead of Dollars. Such conversion can be maintained as long as the MCD304 is located within China, or until a user specifies otherwise.Accordingly, system 300 can provide timesaving conversion featuresassociated with the mobile device credit account 302.

In accordance with specific embodiments, system 300 can include alocation component 306 that can determine a contemporaneous location ofthe MCD 304 or of a target account, or both. A target account can be asecond financial account (e.g., see FIG. 2, supra, at 208) involved in atransaction with credit account 302. Due to the nature of electroniccommunication, the target account can be located in substantially anycountry of the world, and associated with any suitable currency. As aresult, a location of the target account, as well as a location of theMCD 304, can be relevant to determining an appropriate currency(currencies) for a transaction.

Location component 306 can utilize any suitable mechanism fordetermining device/account location. For instance, a global positioningsystem (GPS) associated with the MCD 304 can provide such location.Other mechanisms, such as satellite triangulation systems, cellularbase-station triangulation algorithms, or the like can be used as well.Alternatively, or in addition, an account (e.g., a target accountdiscussed above) or an electronic interface to such account (e.g., MCD304, financial account server 312) can store and provide acontemporaneous or default location of the account/device to thelocation component 306. For example, a mobile phone (304) can have a GPSunit associated with it, and therefore can provide a GPS location to thelocation component 306. In addition, the mobile phone (304) can storedefault information related to credit account 302, such as a defaultlocation for the account (302) or a default currency for the account.If, for instance, the credit account 302 is sponsored by an entitylocated in the United States, and a default ‘location’ of the account isin the United States, such information can also be provided to thelocation component 306. As a further example, a target account (e.g., atarget of a funds transfer) or a device providing an electronicinterface to the target account (e.g., an online transaction server[312]) can specify that a sponsoring entity is located in Europe andutilizes the Euro as a default currency (or other currency-relatedinformation). Information determined by the location component 306 canbe provided to a conversion processor 308 to facilitate converting fundsfrom one currency to another.

In accordance with other aspects, a conversion processor 308 can converta balance of the credit account 302 or a transfer of funds to or fromthe credit account 302 from a first currency to a second currency. Thesecond currency can be, for instance, appropriate for a contemporaneouslocation of the MCD 304 or of a target account, or both. For example, ifthe location component 306 determines the credit account 302 is based inGermany (or, e.g., sponsored by a German financial/commercial entity)and a target account is in Australia, conversion processor 308 canconvert funds transferred between such accounts from German DeutscheMarks (DEM) to Australian Dollars (AUD). Alternatively, if the MCD 304is located in Australia (e.g., determined by location component 306) anda transaction is initiated with an Australian merchant in Australia,funds from the credit account 302 can also be converted from DEM to AUD.

In order to provide accurate, up to date service, conversion processor308 can access an updated database (not depicted) that providescontemporaneous conversion information. Such information can be based ondaily fluctuations in market value of national currencies, or likefactors. In addition, the updated database can be accessed by way of theInternet (or other suitable data network) or a wired or wirelessinterface with a server of a financial institution maintaining suchinformation (e.g., see FIG. 1 at 108). Accordingly, conversion from onecurrency to another as described can be based on up to date conversionratios.

In addition to the foregoing, system 300 can include a managementcomponent that can interface the MCD 304 with a financial account server312 associated with the credit account 302. The management component 310can provide a mechanism for synchronizing the financial account server312 and the MCD 304, in order to update credit account transactions atthe server 312. In such a manner, a financial entity sponsoring thecredit account 302 can supervise transaction activity (e.g., allowing ordenying a transaction). Supervision can be based on concurrent creditbalance, comparison of concurrent credit balances, a ratio of balance tocredit limit, an amount of a requested transaction, or a number oftransactions undertaken in a threshold period of time, or a combinationthereof, associated with the credit account 302 or a target account. Theserver 312 therefore provides a sponsoring credit entity with an abilityto oversee transactions and ensure that rules associated with the creditaccount 302 are followed. As described, system 300 can provideadditional convenience features related to financial transactions in amobile environment.

FIG. 4 illustrates a block diagram of a sample system 400 that canprovide automatic deposit of payroll funds to a mobile credit account402 as described herein. Deposit to the account can be updated at an MCD404 associated with the account by way of an interface to a server of asponsoring entity (not depicted). Accordingly, additional features canbe provided by system 400, either alone or in conjunction with aspectsof the subject innovation described elsewhere herein.

According to specific embodiments, system 400 can include a payrollinterface component 406 that couples the credit account 402 with apayroll server 408 and facilitates automatic deposit of payroll funds tothe credit account 402. The payroll interface component 406 can couplethe payroll server and MCD 404 and/or credit account 402 by way of aremote communication interface 410. The payroll server 408 can be anelectronic interface to any suitable account usable for managingemployer/employee payroll funds. To affect the automatic deposit,payroll interface component 406 can maintain a database that correlatesan employee ID and a credit account 402 owned by a user of the MCD 404(the employee). Funds disbursed to the employee ID by the payroll server408 can be forwarded via the remote communication interface 410 to thecredit account 402 by payroll interface component 406. It should beappreciated that such interface (410) can be any suitable interface forremote communication, described herein or known in the art (e.g., amobile or cellular communication network, satellite communicationnetwork, data network such as the Internet, wired connection to such anetwork and so on).

As described, system 400 can provide an additional conveniencefeature(s) for subscribers of a mobile credit account (402, 404).Automatic payroll deposit can be a desired benefit in a mobile financialenvironment, either alone or in conjunction with other benefits providedherein, such as access to a credit account without need of credit cardor card information, automated currency conversion, or sub-accountcreation and management (see FIG. 5, infra), or the like. As such,system 400 can provide substantial benefit over prior payroll depositmechanisms by incorporating access to and interaction with a depositedaccount via an MCD 404.

FIG. 5 illustrates a block diagram of a sample system that cansub-divide a credit account 502 into sub-accounts (not depicted)sponsored by one or more entities, accumulate and manage benefitsrelated thereto, and distribute credit amongst such accounts. System 500therefore, can take advantage of benefits (e.g., money back rewards,frequent travel points) offered by a credit purveyor by creating asub-account, or adding a credit account, associated with an MCD 504 thatis sponsored by the purveyor. Benefits provided by purveyors can beaggregated at the MCD 504 and displayed to a user in order to organizeand manage the benefits. Accordingly, system 500 can enable a credituser to take advantage of the full range of benefits offered inconjunction with modern credit accounts.

According to particular aspects, system 500 can include a sub-divisioncomponent 506 that can divide a credit account 502 into a plurality ofsub-credit accounts (not depicted), where each of the sub-creditaccounts can be affiliated with either a financial institution or acommercial vendor 508, or like entity that can extend a line of creditto a consumer. A credit line associated with the credit account 502 canbe proportioned amongst the sub-accounts (see below). Alternatively, thesub-division component 506 can associate an additional line of credit tothe sub-account(s), offered by a sponsor (508) of the sub-creditaccount. For example, a user can desire a Starbucks credit accountaffiliated with their mobile credit account (502, 504) in order to takeadvantage of credit benefits associated with such an account (e.g.,money back on Starbucks purchases, discounts on Starbucks products,special promotional offers, acceptance by Starbucks of an MCD account[502, 504] as described herein, or the like). If granted, a Starbuckssub-account can be associated with MCD 504 in a manner similar to thatdescribed herein for a general credit account (502). As a result,qualifying purchases/activity can accrue benefits associated with thesub-account. The sub-account can be afforded credit by a sponsoringentity (508) (e.g., Starbucks) or optionally can be apportioned from acredit limit associated with a general credit account (502) affiliatedwith the MCD 504.

According to further aspects of the claimed subject matter, system 500can include a benefit aggregation component 510 that can compile creditreward benefits provided by a financial institution or commercial vendor508 sponsoring a credit account or sub-account. The benefit aggregationcomponent 510 can store compiled benefits in MCD 504 memory, forinstance. The benefits can be organized within a mobile application thataggregates benefits, keeps track of a state of such benefits, anddisplays the benefits on a display of the MCD 504. Additionally, benefitaggregation component 510 can notify a device user (e.g., by playing anaudio ring tone at the MCD 504, displaying a notification, playing avoice recording, etc.) when a benefit can be used or accrued inconjunction with a transaction. For instance, if an initiatedtransaction involves a purchase of a product that can be discounted byexpending an accrued credit benefit (e.g., credit discount, money backreward, etc.), the MCD 504 can display/playback an announcement of thebenefit. Accordingly, a mobile credit account (502, 504) user can bealerted of accrued/available benefits in order to take advantage of suchbenefits.

According to further embodiments, benefit aggregation component cansynchronize accumulation and expenditure of benefits at the MCD 504 anda credit server 512 associated with the financial institution orcommercial vendor 508 sponsoring an account (502) or sub-account.Benefit aggregation component 510 can utilize a remote communicationinterface (not depicted) to exchange date with the credit server 512, asdescribed herein or known in the art. Particularly, rules associatedwith benefit eligibility, expenditure and/or accumulation can beaccessed at such server 512. Further, expenditure/accrual of creditbenefits at the MCD 504 can be updated to the credit server 512 tofacilitate synchronization of such benefits at the MCD 504 and thefinance/vendor 508 supporting the sub-account.

In addition to the foregoing, system 500 can include a re-distributioncomponent 514 configured to apportion available credit between thecredit account 502 and one or more additional financial accountsassociated with the MCD 504 or a user of the mobile communicationdevice. For instance, if a credit line of a first sub-account isinsufficient to support a particular purchase or transaction,re-distribution component 514 can attempt to apportion available creditassociated with a general credit account (502) or a second sub-accountto the first sub-account. Apportionment of credit can be in accordancewith predetermined rules stored at a rule-set database 516. The rulescan be established by one or more financial/commercial entitiessponsoring the credit account(s) (502), for instance. Particularly, therules can provide guidelines for the re-distribution component 514 toapportion available credit among multiple credit accounts (502)associated with MCD 504. The rules can be based at least in part on aconcurrent credit balance, comparison of concurrent credit balances, aratio of balance to credit limit, an amount of a requested transaction,or a number of transactions undertaken in a threshold period of time, ora combination thereof or of like factors associated with the creditaccount 502 or one or more sub-accounts.

According to additional embodiments, re-distribution component 514 canalso request an extension of credit from a sponsoringfinancial/commercial vendor 508. If a credit line is insufficient tocover a desired transaction, as discussed above, re-distributioncomponent 514 can access a remote server associated with the vendor(508) (e.g., by way of benefit aggregation component 510) andautomatically request an extension of credit for an account (502) orsub-account. If a sufficient extension of credit is granted by theserver 512, the credit account 502 and/or sub-account(s) can be updatedat MCD 504 to reflect the additional line of credit and the transactioncan be completed.

It should be appreciated that the rule-set database 516 can be stored atthe MCD 504 and updated periodically by communication with the creditserver 512, or a remote database accessed by re-distribution component514 via a remote communication interface. System 500, as described,provides for shared credit value amongst multiple accounts. Shared valuecan facilitate optimal use of accounts sponsored by various entities andaccrual of credit-related benefits provided by such entities.Accordingly, system 500 can provide additional management andapportionment benefits for a mobile credit account (502, 504) to assista user in obtaining optimal use of such account, as described herein.

FIG. 6 depicts a block diagram of a sample system 600 that can providesecure interactions for remote credit transfer in accordance with one ormore aspects. Remote communication can be subject to unauthorized accessby third party devices (not depicted). Particularly, concerning remotecredit transactions as described herein, security for remotecommunication can be desired to maintain integrity of a credit account602 and mitigate a likelihood that unauthorized users can access andappropriate funds associated with the credit account 602. System 600 cansecure remote communication at least by encrypting transmitted data, sothat account information cannot be extracted from such transmission, andby requiring user authentication prior to initiating a credittransaction on an MCD 604. It is to be appreciated that other mechanismsfor securing remote transmissions and/or conditioning account (502)access on appropriate identification, known in the art or made known toone of skill in the art by way of the context provided herein, areincorporated into the subject disclosure.

According to one or more aspects, system 600 can include anauthentication component 606 that can condition access to MCD 604 and acredit account 602 associated with the MCD 604 upon providing suitableidentification. For instance, authentication component 606 can requireentry of a username and/or password onto the MCD 604. Alternatively, orin addition, electronic identification technology, such as afinger/thumb print scan device can be employed by the authenticationcomponent 606 to verify an identity of a user of MCD 604. Additionalmechanisms known in the art for identifying an identity of a user at aMCD (604) can also be incorporated in addition to or as alternatives tothose described above. As a result, system 600 can provide a degree ofsecurity by conditioning access to credit or credit transactions by theMCD 604 on providing sufficient proof of identity.

According to further aspects, system 600 can include an encryptiondatabase 610 that can encrypt and decrypt data transmitted and receivedover a remote communication interface 606. Particularly, encryptiondatabase 610 can cryptographically protect and/or digitally sign data todecrease unauthorized, inadvertent and/or malicious access totransmitted data and credit account information. Encryption canessentially enable remote communication between the MCD 604 and afinancial account server 612, including affecting a credit transactionthereby, to be protected.

Encryption database 610 can be used to cryptographically protect dataduring transmission and/or storage between devices (604, 612) or at adevice (604, 612). For instance, an encryption algorithm can be employedto encode data. The algorithm is essentially a mathematical formula usedto turn data into a secret code, unintelligible without access to acorresponding decryption formula or the like. For instance, anencryption algorithm can utilize a string of bits known as a ‘key’ toperform calculations pursuant to the mathematical formula. A largernumber of bits in the key enable the formula to generate a greaternumber of alternative combinations, rendering the code harder to breakand the encrypted data more secure.

A typical encryption algorithm can utilize a block cipher method, whichcodes fixed blocks of input that are typically from 64 to 128 bits (ormore) in length. A decryption database 610 can be used to convertencrypted data back to an un-encrypted form. According to particularaspects, a public key/private key pair can be used to encrypt anddecrypt data upon transmission and receipt, respectively, by the MCD 604or financial account server 612. As described, system 600 can employsuitable mechanisms to secure credit-related data transmitted by the MCD604 and/or financial account server 612 to mitigate unauthorizedintrusion into an associated account (602).

The aforementioned systems have been described with respect tointeraction between several components. It should be appreciated thatsuch systems and components can include those components orsub-components specified therein, some of the specified components orsub-components, and/or additional components. For example, a systemcould include mobile-credit interface component 112, MCD 104, electronicdevice 204, and credit execution component 212, or a differentcombination of these and other components. Sub-components could also beimplemented as components communicatively coupled to other componentsrather than included within parent components. Furthermore, it should benoted that one or more components could be combined into a singlecomponent providing aggregate functionality. For instance, conversionprocessor 308 can include location component 306, or vice versa, tofacilitate determining time, location and/or locale information of anMCD and performing an appropriate currency conversion based on suchdetermination by way of a single component. The components may alsointeract with one or more other components not specifically describedherein but known by those of skill in the art.

Furthermore, as will be appreciated, various portions of the disclosedsystems above and methods below may include or consist of artificialintelligence or knowledge or rule based components, sub-components,processes, means, methodologies, or mechanisms (e.g., support vectormachines, neural networks, expert systems, Bayesian belief networks,fuzzy logic, data fusion engines, classifiers . . . ). Such components,inter alia, and in addition to that already described herein, canautomate certain mechanisms or processes performed thereby to makeportions of the systems and methods more adaptive as well as efficientand intelligent.

In view of the exemplary systems described supra, methodologies that maybe implemented in accordance with the disclosed subject matter will bebetter appreciated with reference to the flow charts of FIG. 7 through9. While for purposes of simplicity of explanation, the methodologiesare shown and described as a series of blocks, it is to be understoodand appreciated that the claimed subject matter is not limited by theorder of the blocks. For instance, some blocks may occur in differentorders and/or concurrently with other blocks from what is depicted anddescribed herein. Moreover, not all illustrated blocks may be requiredto implement the methodologies described hereinafter. Additionally, itshould be further appreciated that the methodologies disclosedhereinafter and throughout this specification are capable of beingstored on an article of manufacture to facilitate transporting andtransferring such methodologies to computers. The term article ofmanufacture, as used, is intended to encompass a computer programaccessible from any computer-readable device, carrier, or media as wellas computer hardware including gates, circuits, and transistors, or thelike.

FIG. 7 illustrates a flowchart of a sample methodology 700 forfacilitating credit transactions for an MCD credit account in accordancewith one or more aspects. Method 700, at 702, can receive a unique ID ofan MCD. The unique ID can be a subscriber identity module (SIM) number,a serial number, or a code generated for purpose of associating the MCDwith a financial account. Further, the unique ID can be any suitablesequence of numbers, letters, characters and/or symbols, of any suitablealphabet. The unique ID can also be encrypted by an encryption formula,as described herein or as known in the art. According to additionalaspects, the unique ID can be received by way of a local communicationinterface, such as an electronic bus structure connecting two or moreelectronic devices, or a remote communication architecture as describedherein.

Method 700, at 704, can associate a sponsored credit account with theunique ID. To accommodate this association, the unique ID can be pairedwith an owner, subscriber and/or user (referred to collectively asowner) of the MCD, for instance. As a particular example, an identifierassociated with the owner can be paired or included within the unique IDof the MCD. Such identifier can be a PIN number or social securitynumber, etc., that can uniquely identify the owner of the MCD. Credithistory associated with the owner can be obtained utilizing theidentifier (e.g., by way of a credit check with a commercial creditreporting agency) upon receipt of the unique ID, or upon pairing theidentifier with the unique ID, or at any suitable prior and/orsubsequent time.

According to particular aspects, the credit account can be sponsored byone or more commercial and/or financial entities (e.g., a bank, lendingcompany, credit agency, commercial retail vendor, online retail vendor,or a combination of commercial vendor(s) and lending entities, and soon). Such entities can extend a line of credit for the credit account.By associating the credit account with the MCD, the line of credit isfurther extended to an owner of the MCD by way of the unique ID (and,e.g., owner identifier paired with the unique ID).

Method 700, at 706, can synchronize transaction information at the MCDand at a financial account server. For instance, information related toa concurrent balance, recent transaction history, or the like can beupdated at the MCD and the financial account server. According toparticular aspects, the financial account server can be operated by anentity (e.g., financial and/or commercial entity) sponsoring the creditaccount. As a result, by synchronizing information related to theaccount at both the MCD and the account server, the sponsoring entitycan supervise and/or manage the credit account. For instance, billingstatements and summaries can be compiled and sent to an MCD owner, andso on. The synchronization can occur by way of any suitable remotecommunication architecture. Examples can include a mobile communicationnetwork, a data network such as the Internet or an intranet (and/or,e.g., an Internet Protocol [IP] interface to such data network includinga DSL line, cable IP line, satellite Internet connection, and so on), asatellite network, or even an optical and/or RF scanner/transmitterpair, or any suitable combination thereof or of the like.

According to still other aspects, a link between the MCD and an accountserver can be initiated prior to accomplishing a transaction. The linkcan be used to obtain authorization to conduct a transaction, forinstance. If such is the case, synchronization of transaction-relatedinformation at the MCD and account server could also occurcontemporaneous with execution of a transaction. Where authorization isnot obtained via a direct link to the account server prior to and/orcontemporaneous with executing the transaction, a set of transactionrules can be consulted and be used to guide the transaction. As aspecific example, an MCD can contain a transaction authorizationapplication stored at the MCD. The application can contain requirementsspecifying when a transaction can be conducted. If the requirements aremet, the transaction can be executed, if not, the transaction is notexecuted, and the MCD can display a reason for the failed transaction.Under these circumstances, transactions can occur even if acontemporaneous link with the account server cannot be made at the timeof the transaction (e.g., in an area with insufficient cellularcoverage). Details about the transaction can be synchronized between theMCD and the account server at a suitable time in which such a link canbe maintained.

As described, method 700 can provide for personal and/or commercialcredit activity and transactions without use of a credit card orassociated credit account information (e.g., account number, expirationdate, etc.). An MCD, commonly carried for personal communications andcomputing, can initiate, manage and execute the credit activity instead.An account server of a sponsoring entity can be consulted prior tocompleting the transaction (e.g., to obtain approval) or after thetransaction, to maintain synchronized account records at the MCD andaccount server. Accordingly, an interface between a credit purveyor anda consumer can utilize any suitable remote communication architecture,including wireless, to provide truly mobile credit access. A greatbenefit can be provided by the subject disclosure, as conventionalmechanisms typically required at least a stationary connection to acredit server (e.g., over a phone line) by a merchant to complete acredit transaction. Instead, the subject innovation provides for trulymobile credit transactions, greatly enhancing consumer mobility andspending power.

FIG. 8 depicts a flowchart of a sample methodology 800 for providingmanagement of MCD credit and credit sub-accounts according to additionalaspects. Method 800, at 802, can establish a synchronized MCD creditaccount. Such a credit account can be established in substantiallysimilar manner as described with respect to FIG. 7, supra. At 804, aninterface to a second device can be provided enabling an exchange offunds between the MCD credit account and an account of the seconddevice. The second device can be an ATM, an electronic cash register, anonline server/database, a second MCD, an electronic server of a bank orlending institution, and so on. The second device can further beassociated with one or more financial accounts (e.g., including achecking, savings, credit, certificate of deposit, money market account,or the like), such that the exchange of funds between the MCD creditaccount and the second device involves a credit or debit to the creditaccount of the MCD device and a corresponding debit or credit,respectively, to an account(s) associated with the second device. Theexchange of funds can be a purchase of goods or services, payment of abill, peer to peer credit transfer, transfer via a credit voucher, asdescribed herein, or the like. In such a manner, commercial or peer topeer credit transactions can be accomplished utilizing at least one MCD.

At 806, a credit account associated with the MCD can be fractured intoone or more sub-accounts. The sub-account(s) can be sponsored by one ormore commercial and/or financial entities. At 808, a transfer rule-setcan be consulted. The transfer rule-set can establish guidelines fordetermining whether available credit can be transferred from a firstcredit account (e.g., including a general credit account and/or one ormore sub-accounts) to a second credit account associated with the MCD.At 810, a determination as made as to whether such a transfer can beaccomplished in accordance with the guidelines. If so, method 800proceeds to reference number 812 where credit is transferred amongcredit accounts associated with the MCD. At 814, benefits accrued fromactivity associated with sponsored accounts (e.g., including the generalcredit account and/or sub-accounts) are aggregated, stored and managedat the MCD. Benefits can include money back rewards, frequent usagepoints, frequent traveler points, discounts for merchandise and/orservices provided by a particular vendor sponsoring an account(s) orbusiness partners of a sponsor, and so on.

If, at 810, credit could not be transferred among accounts associatedwith the MCD in accordance with transfer guidelines, methodology 800 canproceed to 816 where a second determination can be made as to whether acredit increase is available for an account/sub-account. The creditincrease can be based on additional guidelines governing credit limitincreases (e.g., utilizing credit history of an owner of the MCD) storedat the MCD, or based on a credit limit extension approval provided by asponsoring entity, as described herein. If, at 816, no credit increaseis available for one of the sub-accounts, methodology 800 proceeds to818 where a transaction is conducted utilizing only a general creditaccount associated with the MCD, if available. If a credit increase isavailable at 816, methodology 800 proceeds to 820 where a transactioncan be initiated based on increased credit afforded to anaccount/sub-account.

As described, method 800 provides a logical flow governing management ofa general purpose credit account at an MCD as well as additionalsub-accounts. The sub-accounts, sponsored by a commercial and/orfinancial entity, can accrue valuable commercial benefits, such asfrequent traveler miles and commercial/financial discounts. As a result,management and organization of sponsored sub-accounts can increase thevalue of such discounts and aid in maximizing potential savings andresulting benefits for an owner of the MCD.

Referring now to FIG. 9, a flowchart of an example methodology 900 isdepicted for providing automated currency conversion for an MCD creditaccount based on contemporaneous location. Method 900, at 902, canestablish a synchronized MCD credit account, as described herein. At904, a time, location, and/or locale of the MCD can be determined. Timeinformation can be obtained by way of a clock-type application storedand executed at the MCD. The time can be for a predetermined time zone(e.g., Eastern Standard Time, Eastern Daylight Time, and so on) or for atime zone specified/selected at the MCD. Alternatively, or in addition,time information can be obtained by a remote connection with acommunication network, such as a cellular network or the Internet, whichcan provide concurrent time information for one or more time zones.Location information can be determined by any suitable locationdetermination technique, such as triangulation algorithms utilized bycellular/mobile base stations maintaining a radio link with the MCD,satellite positioning systems (SPS), global positioning systems (GPS),or the like. Locale information can be determined by cross-reference thelocation with a data network and/or information server of acellular/mobile network. For instance, such network/database canindicate that a particular location is near an urban area or rural area.More specifically, a location can be proximate a shopping district,downtown district of a metropolitan area, red light district, theatredistrict, sporting arena, and so on.

Method 900, at 906, can convert credit to an appropriate currency basedon the time, location and/or locale information determined at referencenumber 904. More specifically, a transaction conducted in a particularregion of the world (e.g., Germany) can be converted from a defaultcurrency to DEM, for instance. Additionally, if it can be determined(e.g., from the locale information) that an area of Germany that an MCDis concurrently at has a high Chinese population (e.g., a ‘Chinesedistrict’ of a German metropolitan area), the MCD can offer to convertfunds involved in a credit transaction into Chinese Yen, for instance.As a result, methodology 900 can automatically determine pertinentinformation related to commercial transactions based on time, locationand locale information associated with an MCD, and provide automatedconversion of currency from a default currency to one more suited to thedetermined information.

Referring now to FIG. 10, there is illustrated a block diagram of anexemplary computer system operable to execute aspects of the disclosedsubject matter. In order to provide additional context for variousaspects of the subject invention, FIG. 10 and the following discussionare intended to provide a brief, general description of a suitablecomputing environment 1000 in which the various aspects of the inventioncan be implemented. Additionally, while the invention has been describedabove in the general context of computer-executable instructions thatmay run on one or more computers, those skilled in the art willrecognize that the invention also can be implemented in combination withother program modules and/or as a combination of hardware and software.

Generally, program modules include routines, programs, components, datastructures, etc., that perform particular tasks or implement particularabstract data types. Moreover, those skilled in the art will appreciatethat the inventive methods can be practiced with other computer systemconfigurations, including single-processor or multiprocessor computersystems, minicomputers, mainframe computers, as well as personalcomputers, hand-held computing devices, microprocessor-based orprogrammable consumer electronics, and the like, each of which can beoperatively coupled to one or more associated devices.

The illustrated aspects of the invention may also be practiced indistributed computing environments where certain tasks are performed byremote processing devices that are linked through a communicationsnetwork. In a distributed computing environment, program modules can belocated in both local and remote memory storage devices.

A computer typically includes a variety of computer-readable media.Computer-readable media can be any available media that can be accessedby the computer and includes both volatile and nonvolatile media as wellas removable and non-removable media. By way of example, and notlimitation, computer-readable media can comprise computer storage mediaand communication media. Computer storage media can include volatileand/or nonvolatile, removable and non-removable media implemented in anysuitable method or technology for storage of information such ascomputer-readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disk (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by the computer.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and includesany information delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wired media such as awired network or direct-wired connection, and wireless media such asacoustic, RF, infrared and other wireless media. Combinations of the anyof the above should also be included within the scope ofcomputer-readable media.

With reference again to FIG. 10, the exemplary environment 1000 forimplementing various aspects of the invention includes a computer 1002,the computer 1002 including a processing unit 1004, a system memory 1006and a system bus 1008. The system bus 1008 couples components of system1000 including, but not limited to, the system memory 1006 to theprocessing unit 1004. The processing unit 1004 can be any of variouscommercially available processors. Dual microprocessors and othermulti-processor architectures may also be employed as the processingunit 1004.

The system bus 1008 can be any of several types of bus structure thatmay further interconnect to a memory bus (with or without a memorycontroller), a peripheral bus, and a local bus using any of a variety ofcommercially available bus architectures. The system memory 1006includes read-only memory (ROM) 1010 and random access memory (RAM)1012. A basic input/output system (BIOS) is stored in a non-volatilememory 1010 such as ROM, EPROM, EEPROM, which BIOS contains the basicroutines that help to transfer information between elements within thecomputer 1002, such as during start-up. The RAM 1012 can also include ahigh-speed RAM such as static RAM for caching data.

The computer 1002 further includes an internal hard disk drive (HDD)1014 (e.g., EIDE, SATA), which internal hard disk drive 1014 may also beconfigured for external use in a suitable chassis (not shown), amagnetic floppy disk drive (FDD) 1016, (e.g., to read from or write to aremovable diskette 1018) and an optical disk drive 1020, (e.g., readinga CD-ROM disk 1022 or, to read from or write to other high capacityoptical media such as the DVD). The hard disk drive 1014, magnetic diskdrive 1016 and optical disk drive 1020 can be connected to the systembus 1008 by a hard disk drive interface 1024, a magnetic disk driveinterface 1026 and an optical drive interface 1028, respectively. Theinterface 1024 for external drive implementations includes at least oneor both of Universal Serial Bus (USB) and IEEE1394 interfacetechnologies. Other external drive connection technologies are withincontemplation of the subject invention.

The drives and their associated computer-readable media providenonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For the computer 1002, the drives and mediaaccommodate the storage of any data in a suitable digital format.Although the description of computer-readable media above refers to aHDD, a removable magnetic diskette, and a removable optical media suchas a CD or DVD, it should be appreciated by those skilled in the artthat other types of media which are readable by a computer, such as zipdrives, magnetic cassettes, flash memory cards, cartridges, and thelike, may also be used in the exemplary operating environment, andfurther, that any such media may contain computer-executableinstructions for performing the methods of the invention.

A number of program modules can be stored in the drives and RAM 1012,including an operating system 1030, one or more application programs1032, other program modules 1034 and program data 1036. All or portionsof the operating system, applications, modules, and/or data can also becached in the RAM 1012. It is appreciated that the invention can beimplemented with various commercially available operating systems orcombinations of operating systems.

A user can enter commands and information into the computer 1002 throughone or more wired/wireless input devices, e.g., a keyboard 1038 and apointing device, such as a mouse 1040. Other input devices (not shown)may include a microphone, an IR remote control, a joystick, a game pad,a stylus pen, touch screen, or the like. These and other input devicesare often connected to the processing unit 1004 through an input deviceinterface 1042 that is coupled to the system bus 1008, but can beconnected by other interfaces, such as a parallel port, an IEEE1394serial port, a game port, a USB port, an IR interface, etc.

A monitor 1044 or other type of display device is also connected to thesystem bus 1008 via an interface, such as a video adapter 1046. Inaddition to the monitor 1044, a computer typically includes otherperipheral output devices (not shown), such as speakers, printers, etc.

The computer 1002 may operate in a networked environment using logicalconnections via wired and/or wireless communications to one or moreremote computers, such as a remote computer(s) 1048. The remotecomputer(s) 1048 can be a workstation, a server computer, a router, apersonal computer, portable computer, microprocessor-based entertainmentappliance, a peer device or other common network node, and typicallyincludes many or all of the elements described relative to the computer1002, although, for purposes of brevity, only a memory/storage device1050 is illustrated. The logical connections depicted includewired/wireless connectivity to a local area network (LAN) 1052 and/orlarger networks, e.g., a wide area network (WAN) 1054. Such LAN and WANnetworking environments are commonplace in offices and companies, andfacilitate enterprise-wide computer networks, such as intranets, all ofwhich may connect to a global communications network, e.g., theInternet.

When used in a LAN networking environment, the computer 1002 isconnected to the local network 1052 through a wired and/or wirelesscommunication network interface or adapter 1056. The adapter 1056 mayfacilitate wired or wireless communication to the LAN 1052, which mayalso include a wireless access point disposed thereon for communicatingwith the wireless adapter 1056.

When used in a WAN networking environment, the computer 1002 can includea modem 1058, or is connected to a communications server on the WAN1054, or has other means for establishing communications over the WAN1054, such as by way of the Internet. The modem 1058, which can beinternal or external and a wired or wireless device, is connected to thesystem bus 1008 via the serial port interface 1042. In a networkedenvironment, program modules depicted relative to the computer 1002, orportions thereof, can be stored in the remote memory/storage device1050. It will be appreciated that the network connections shown areexemplary and other means of establishing a communications link betweenthe computers can be used.

The computer 1002 is operable to communicate with any wireless devicesor entities operatively disposed in wireless communication, e.g., aprinter, scanner, desktop and/or portable computer, portable dataassistant, communications satellite, any piece of equipment or locationassociated with a wirelessly detectable tag (e.g., a kiosk, news stand,restroom), and telephone. This includes at least Wi-Fi and Bluetooth™wireless technologies. Thus, the communication can be a predefinedstructure as with a conventional network or simply an ad hoccommunication between at least two devices.

Wi-Fi, or Wireless Fidelity, allows connection to the Internet from acouch at home, a bed in a hotel room, or a conference room at work,without wires. Wi-Fi is a wireless technology similar to that used in acell phone that enables such devices, e.g., computers, to send andreceive data indoors and out; anywhere within the range of a basestation. Wi-Fi networks use radio technologies called IEEE802.11 (a, b,g, etc.) to provide secure, reliable, fast wireless connectivity. AWi-Fi network can be used to connect computers to each other, to theInternet, wired networks (which use IEEE802.3 or Ethernet), etc. Wi-Finetworks operate in the unlicensed 2.4 and 5 GHz radio bands, at an 11Mbps (802.11a) or 54 Mbps (802.11b) data rate, for example, or withproducts that contain both bands (dual band), so the networks canprovide real-world performance similar to the basic 9BaseT wiredEthernet networks used in many offices.

Referring now to FIG. 11, there is illustrated a schematic block diagramof an exemplary remote communication environment operable to executeaspects of the disclosed subject matter. The system 1100 includes one ormore client(s) 1110. The client(s) 1110 can be hardware and/or software(e.g., threads, processes, computing devices). The client(s) 1110 canhouse cookie(s) and/or associated contextual information related to dataexchanged between a first remote device (1110) (e.g., including a MCD)and a second remote device (1130) (e.g., including a financial accountserver) as described herein, for example.

The system 1100 also includes one or more server(s) 1130. The server(s)1130 can also be hardware and/or software (e.g., threads, processes,computing devices). The servers 1130 can house threads to performtransformations by employing the invention, for example. One possiblecommunication between a client 1110 and a server 1130 can be in the formof a data packet adapted to be transmitted between two or more computerprocesses. The data packet may include a cookie and/or associatedcontextual information, for example. The system 1100 includes acommunication framework 1150 (e.g., a global communication network suchas the Internet) that can be employed to facilitate communicationsbetween the client(s) 1110 and the server(s) 1130.

Communications can be facilitated via a wired (including optical fiber)and/or wireless technology. The client(s) 1110 are operatively connectedto one or more client data store(s) 1160 that can be employed to storeinformation local to the client(s) 1110 (e.g., cookie(s) and/orassociated contextual information). Similarly, the server(s) 1130 areoperatively connected to one or more server data store(s) 1140 that canbe employed to store information local to the servers 1130.

What has been described above includes examples of the variousembodiments. It is, of course, not possible to describe everyconceivable combination of components or methodologies for purposes ofdescribing the embodiments, but one of ordinary skill in the art mayrecognize that many further combinations and permutations are possible.Accordingly, the detailed description is intended to embrace all suchalterations, modifications, and variations that fall within the spiritand scope of the appended claims.

In particular and in regard to the various functions performed by theabove described components, devices, circuits, systems and the like, theterms (including a reference to a “means”) used to describe suchcomponents are intended to correspond, unless otherwise indicated, toany component which performs the specified function of the describedcomponent (e.g., a functional equivalent), even though not structurallyequivalent to the disclosed structure, which performs the function inthe herein illustrated exemplary aspects of the embodiments. In thisregard, it will also be recognized that the embodiments includes asystem as well as a computer-readable medium having computer-executableinstructions for performing the acts and/or events of the variousmethods.

In addition, while a particular feature may have been disclosed withrespect to only one of several implementations, such feature may becombined with one or more other features of the other implementations asmay be desired and advantageous for any given or particular application.Furthermore, to the extent that the terms “includes”, “including”, orvariants thereof are used in either the detailed description or theclaims, these terms are intended to be inclusive in a manner similar tothe term “comprising”.

What is claimed is:
 1. A method for synchronizing a mobile communicationdevice (MCD) with a credit account, comprising: associating a unique IDof a MCD with a credit account, the unique ID corresponding to a user ofthe MCD, the credit account sponsored by a financial entity; initiatinga transaction on behalf of the MCD; and synchronizing a server of thefinancial entity with the MCD based on the transaction initiated by theMCD, at least some of at least one of the associating, initiating, orsynchronizing implemented at least in part via a processing unit.
 2. Themethod of claim 1, comprising: obtaining transaction approval for thetransaction; and synchronizing the server of the financial entity basedon the transaction approval.
 3. The method of claim 2, comprisingobtaining transaction approval based on one or more predeterminedtransaction rules and no link between the server of the financial entityand the MCD.
 4. The method of claim 1, the synchronizing comprisingsynchronizing a state of the credit account on the server of thefinancial entity with a state of the credit account on the MCD.
 5. Themethod of claim 1, the synchronizing based on at least one of a creditlimit, credit balance, transaction history, expenditure, payment, debit,or credit associated with the credit account.
 6. The method of claim 1,comprising suggesting a transaction to the user of the MCD based on atleast one of a benefit of the credit account or a benefit of asub-credit account of the credit account
 7. The method of claim 1,comprising calculating a local tax based on the transaction and alocation of the MCD.
 8. The method of claim 1, comprising converting afirst currency of the transaction to a second currency based on at leastone of a location of the MCD or a locale of the MCD.
 9. The method ofclaim 1, comprising encrypting at least one of the unique ID of the MCD,data associated with the transaction, or data associated withsynchronization between the server of the financial entity and the MCD.10. The method of claim 1, comprising: dividing the credit account intoone or more sub-credit accounts; and apportioning credit from a creditline of the credit account to at least some of the one or moresub-credit accounts.
 11. A system for synchronizing a mobilecommunication device (MCD) with a credit account, comprising: amobile-credit interface component configured to associate a unique ID ofa MCD with a credit account, the unique ID corresponding to a user ofthe MCD, the credit account sponsored by a financial entity; a creditexecution component configured to initiate a transaction on behalf ofthe MCD; and a management component configured to synchronize a serverof the financial entity with the MCD based on the transaction initiatedby the MCD, at least some of at least one of mobile-credit interfacecomponent, the credit execution component, or the management componentimplemented at least in part via a processing unit.
 12. The system ofclaim 11, the credit execution component configured to calculate atleast one of a local tax, a fee, or a surcharge for the transactionbased on at least one of a location of the MCD or a locality of the MCD.13. The system of claim 11, comprising a remote communication interfaceconfigured to communicatively couple the MCD to a second electronicdevice, the second electronic device associated with a second unique IDand a second credit account.
 14. The system of claim 11, the creditexecution component configured to initiate the transaction on behalf ofthe MCD and at least one of: transfer funds from the credit accountassociated with the MCD to the second credit account associated with thesecond electronic device; or transfer funds from the second creditaccount associated with the second electronic device to the creditaccount associated with the MCD.
 15. The system of claim 11, comprisinga payroll interface component configured to: correlate an employee ID ofthe user of the MCD with the credit account; and disburse payroll fundsto the credit account based on the employee ID and payroll informationfrom a payroll server.
 16. The system of claim 11, comprising are-distribution component configured to apportion credit from a creditline to at least one of the credit account, one or more sub-creditaccounts of the credit account, or one or more additional financialaccounts.
 17. A computer readable storage medium including executableinstructions, which when executed on a processor perform a methodcomprising: associating a unique ID of a MCD with a credit account, theunique ID corresponding to a user of the MCD, the credit accountsponsored by a financial entity; initiating a transaction on behalf ofthe MCD; and synchronizing a server of the financial entity with the MCDbased on the transaction initiated by the MCD.
 18. The computer readablestorage medium of claim 17, comprising suggesting use of a benefitassociated with the credit account in conjunction with the transactionbased on a benefit availability.
 19. The computer readable storagemedium of claim 17, comprising determining a location of the MCD. 20.The computer readable storage medium of claim 17, comprising supervisingthe transaction based on at least one of a credit balance, utilizationratio, or a number of transactions within a time period.